Summary

When BEDROCK_ENABLE_CACHING=true, BedrockProvider::converse() currently places cache points on the first three visible messages. This doesn't match how Anthropic and Bedrock actually look up cached prefixes: cache entries are keyed by the hash of the prefix ending at the breakpoint, and reads walk backward up to 20 blocks looking for prior writes. With a breakpoint fixed to early messages, every turn reprocesses everything appended after position 3, which in an agent loop grows linearly with turn count.

This change places the cache point on the trailing message instead. On each new turn the lookback finds the breakpoint the previous turn wrote, so fresh processing is bounded to the content added since the last request. This matches the pattern Anthropic's prompt caching documentation recommends for growing conversations:

Place cache_control on the last block whose prefix is identical across the requests you want to share a cache. In a growing conversation the final block works as long as each turn adds fewer than 20 blocks.

The system-prompt cache point is unchanged. The misleading comment about "caching recent messages would shift positions each turn" is replaced with an accurate description of the lookup model.

For a worked cost comparison over a 10-turn agent loop and links to the relevant Anthropic and Bedrock docs, see the linked issue.

Testing

• cargo fmt --all
• cargo check -p goose
• cargo clippy -p goose --all-targets -- -D warnings (no warnings)
• cargo test -p goose --lib providers::bedrock (4 passed)
• cargo test -p goose --lib providers::formats::bedrock (11 passed)

No test changes were needed. The existing per-message helper tests in providers::formats::bedrock exercise to_bedrock_message_with_caching directly with enable_caching=true and are unaffected. The test_caching_* tests in providers::bedrock assert on should_enable_caching() returning the right boolean and are also unaffected.

Related Issues

Relates to #8915